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ABSTRACT 

This  paper  documents  one  proposed  approach  for  transitioning  the  Integrated  Network  Enhanced 
Telemetry  (iNET)  Standards  into  the  IRIG  106  Part  2  Telemetry  Network  Standards.  Describing 
the  iNET  Standards  in  terms  of  the  Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP) 
Model  provides  a  solid  foundation  for  the  proposed  IRIG  106  Part  2  chapter  structure.  The 
proposed  approach  incorporates  an  application-centric  paradigm  by  emphasizing  application-to- 
application  communication.  One  change  proposal  augments  the  current  Simple  Network 
Management  Protocol  (SNMP)  application  protocol  with  a  Hypertext  Transfer  Protocol  (HTTP) 
application  protocol  that  enables  advanced  data  transfer  features  and  other  options.  Another 
change  proposal  includes  Data  Channel  enhancements  resulting  in  a  more  harmonious 
relationship  between  statically  and  dynamically-defined  Data  Channels.  This  paper  includes  a 
high  level  transition  plan  for  migrating  towards  this  proposed  approach  for  IRIG  106  Part  2. 


INTRODUCTION 

The  Central  Test  and  Evaluation  Investment  Program  (CTEIP)  launched  the  iNET  project  to  help 
develop  capabilities  to  support  the  increasing  needs  for  test  and  evaluation  of  modem  and 
upcoming  military  vehicles  and  systems  [1],  By  augmenting  traditional  point-to-point  telemetry 
links  with  Internet  Protocol  (IP)  networks,  flight  test  capabilities  could  be  greatly  enhanced.  A 
key  iNET  project  objective  was  to  develop  a  set  of  well-established  and  validated 
interoperability  standards  (referred  to  as  the  iNET  Standards)  with  the  ultimate  goal  of 
incorporating  those  standards  into  the  Range  Commander’s  Council  (RCC)  IRIG  106  Telemetry 
Standards  [1].  In  2013,  the  RCC  Telemetry  Group  (TG)  initiated  a  task  to  review  the  iNET 
Standards  and  formulate  an  approach  for  transitioning  the  iNET  Standards  into  the  IRIG  106  Part 
2  Telemetry  Network  Standards.  This  paper  documents  one  proposed  approach  for  the 
transition.  Furthermore,  this  paper  identifies  several  change  proposals  that  the  RCC  TG  may 
take  under  consideration  for  inclusion  into  IRIG  106  Part  2.  Familiarity  with  the  iNET  Standards 
is  assumed;  for  this  proposed  approach  to  IRIG  106  Part  2,  the  iNET  abbreviation  “TmNS”  has 
been  repurposed  from  “Telemetry  Network  System ”  to  “Telemetry  Network  Standards ”. 
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INET  STANDARDS  LAYERED  ON  TCP/IP  MODEL 


The  iNET  Standards  consist  of  four  documents:  Test  Article  (TA)  Standard  [2],  System 
Management  (SM)  Standard  [3],  Metadata  Standard  [4],  and  Radio  Access  Network  (RAN) 
Standard  [5].  These  standards  reference  many  existing  protocols,  most  of  which  are  part  of  the 
TCP/IP  Protocol  Suite.  Figure  1  illustrates  the  Open  Systems  Interconnection  (OSI)  Model,  the 
corresponding  TCP/IP  Model,  and  the  major  components  of  the  TCP/IP  Protocol  Suite.  Figure  2 
represents  the  iNET-specific  protocols  layered  onto  the  TCP/IP  Model. 
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Figure  1.  OSI  and  TCP/IP  Model  with  TCP/IP  Protocol  Suite 
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Figure  2.  iNET-specific  Protocols  Layered  onto  the  TCP/IP  Model 
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INET  STANDARDS  OVERVIEW 


The  iNET  System  Management  Protocols  (iNET  SM  Protocols)  are  implemented  by  all  TmNS 
Applications;  SNMP  is  the  primary  application  protocol.  The  iNET  SM  Protocols  include  a 
Configuration  Protocol  for  configuring  an  application  using  a  Metadata  Language  (MDL) 
Instance  Document.  Data  transfer  applications  use  the  Latency/Throughput  Critical  (LTC)  and 
Reliability  Critical  (RC)  Delivery  Protocols  to  exchange  measurement  data  in  the  form  of 
Metadata-defined  TmNS  Data  Messages.  The  Radio  Frequency  (RF)  Network  Management 
applications  use  RF  Network  and  Link  Management  Protocols  to  control  the  transmission  of  data 
across  the  shared  RF  link.  The  iNET  Standards  leverage  the  existing  TCP/IP  Model’s  Transport 
and  Internet  Layer  Protocols  so  the  messages  passed  between  the  Application  Layer  protocols 
and  the  Network  Access  Layer  are  standard  TCP  segments  and  User  Datagram  Protocol  (UDP) 
datagrams  encapsulated  in  IP  datagrams.  The  RF  Link  and  Physical  Layers  transport  IP 
datagrams  across  the  RF  Link.  The  RF  Link  Layer  incorporates  a  Time-Division  Multiple 
Access  channel  access  method  for  sharing  RF  spectrum  between  multiple  participants.  The  RF 
physical  layer  modulation  uses  an  RCC-TG  defined  modified  version  of  the  MIL-STD-188-181 
Single-carrier  Offset  Quadrature  Phase  Shift  Keying,  abbreviated  as  SOQPSK-TG. 

From  a  high  level  perspective,  the  iNET  Standards  may  be  partitioned  into  the  Radio  Access 
Network  (RAN)  Standard  and  a  set  of  application  standards.  The  RAN  Standard  encompasses 
the  RF  Physical  and  Link  Layers  as  well  as  all  applications  required  to  manage  the  shared  RF 
spectrum.  The  RAN  Standard  provides  the  infrastructure  for  managing  the  IP  wireless  networks 
between  Test  Article  applications  and  Ground  applications.  The  application  standards  include 
standards  for  application  configuration,  control,  and  status;  standards  for  measurement  data 
transfer  between  applications;  and  standards  for  describing  application  configurations  and  the 
structure  of  application  data  messages.  The  application  standards  define  the  interoperability 
between  applications  communicating  via  the  IP  network.  The  RAN  Standard  provides  the  IP 
interconnectivity  but  without  the  application  standards,  there  would  be  little  vendor-independent 
interoperability  between  Test  Article  applications  and  Ground  applications.  Driven  by  the 
critical  relationship  between  application  standards  and  application  interoperability,  the 
proposed  approach  to  IRIG  106  Part  2  focuses  on  standardizing  application-to-application 
communication. 


PROPOSED  IRIG  106  PART  2  CHAPTER  STRUCTURE 

The  IRIG  Standard  106-13  Part  1,  Telemetry  Standards,  contain  Chapters  1-10  and  a  set  of 
appendixes  labeled  Appendix  A,  B,  etc.  The  RCC-TG  initially  defined  a  second  part  to  IRIG 
106  named  “IRIG  Standard  106-xx  Part  2,  Telemetry  Network  Standards”.  To  avoid  any 
potential  ambiguity  with  the  existing  IRIG  106  Part  1  chapters,  the  proposed  approach  is  to  start 
IRIG  106  Part  2  with  Chapter  21  and  have  the  appendixes  labeled  Appendix  AA,  BB,  etc.  With 
this  chapter  structure,  the  RCC-TG  has  the  option  of  restoring  IRIG  106  to  a  single  Telemetry 
Standard  where  the  chapters  above  Chapter  20  are  part  of  the  Telemetry  Network  Standards 
section  (this  is  an  option  for  the  RCC-TG  to  consider). 

The  RCC-TG  was  presented  with  the  following  proposed  refactoring  of  the  iNET  Standards  to 
consider  for  IRIG  106  Part  2: 
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1 .  Split  the  TA  Standard  into  three  chapters: 

a.  Core  Protocol  Suite  Chapter:  identifies  all  of  the  core  protocols  available  for  use 
by  a  TmNS  Application  and  the  RF  Link  and  Physical  Layers. 

b.  Application  Messages  Chapter:  defines  application  level  messages  and  includes 
the  TmNS  Message  structure  definition. 

c.  Application  Data  Transfer  Chapter:  includes  the  existing  LTC  and  RC  Delivery 
Protocols  and  includes  a  change  proposal  to  define  an  HTTP-based  Data  Channel 
protocol  for  transferring  TmNS  Messages  between  applications. 

2.  Abstract  the  SNMP  Management  Information  Base  (MIB)  variables  as  Application 
Resources.  The  majority  of  the  System  Management  Standard  is  included  in  the 
Application  Resources  Chapter. 

3.  Include  only  top-level  descriptive  information  in  the  Metadata  Chapter;  the  MDL  schema 
already  includes  the  explicit  element  definitions. 

4.  Split  the  RAN  Standard  in  two  chapters: 

a.  RF  Network  Access  Layer  Chapter:  defines  the  RF  Link  and  Physical  Layers. 

b.  Radio  Access  Network  Management  Chapter:  defines  the  Application  Layer 
protocols  for  controlling  and  monitoring  the  RAN. 

5.  Include  the  MDL  Extensible  Markup  Language  (XML)  Schema  and  TmNS  MIB 
documentation  in  Appendixes. 

6.  Propose  creation  of  TmNS  Engineers  Handbooks  to  capture  Metadata  Language  Best 
Practices,  RAN  Supplemental  Information,  Quality  of  Service  Management,  and 
Application  Development. 

Figure  3  contains  the  proposed  IRIG  106  Part  2  Telemetry  Network  Standards  Table  of  Contents. 
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Figure  3.  Proposed  IRIG  106  Part  2  Telemetry  Network  Standards  Table  of  Contents 
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Figure  4  represents  the  proposed  IRIG  106  Part  2-specific  protocols  layered  onto  the  TCP/IP 
Model  along  with  the  proposed  IRIG  106  Part  2  chapter  references. 


Figure  4.  Proposed  IRIG  106  Part  2-specific  Protocols  Layered  onto  the  TCP/IP  Model 


APPLICATION  RESOURCES 

Application-to-application  communication  is  an  integral  part  of  the  iNET  Standards.  Each 
application  implements  an  SNMP  Agent  with  a  set  of  common  and  application-specific  MIB 
variables.  The  proposed  approach  to  IRIG  106  Part  2  abstracts  these  MIB  variables  along  with 
other  functions  into  a  set  of  application  resources.  Application  communication  occurs  when  one 
application  accesses  another  application’s  resources.  Many  SNMP  resources  (i.e.,  MIB 
variables)  implement  specific  functions  (e.g.,  Data  Source  Transmit  Enable)  while  some  SNMP 
resources  define  a  communication  protocol  (e.g.,  Configuration  Protocol).  SNMP  resources  are 
sufficient  for  simple  control  functions,  but  may  not  be  the  optimal  application  protocol  for  more 
complex  application-to-application  communication  requirements. 

One  proposed  addition  to  IRIG  106  Part  2  enhances  the  iNET  System  Management  philosophy 
by  augmenting  the  SNMP  resources  with  HTTP  resources.  As  compared  to  SNMP,  HTTP 
coupled  with  XML  technology  provides  the  foundation  for  more  robust  and  extensible 
communication  protocols.  The  iNET  Standards  SNMP  resources  along  with  HTTP  resources 
(and  possibly  other  non-SNMP  resources)  could  be  placed  under  a  single  all-encompassing 
TmNS  Application  Resources  Hierarchy.  This  hierarchy  identifies  each  application  resource  and 
the  applicable  application  layer  protocol.  A  possible  addition  to  this  hierarchy  would  be  the 
Instrumentation  Hardware  Abstract  Language  (IHAL)  from  IRIG  106  Part  1  Chapter  9.  Figure  5 
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represents  the  top  tier  of  one  possible  TmNS  Application  Resources  Hierarchy;  the  RCC  TG 
would  ultimately  be  responsible  for  defining  the  hierarchy. 
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Figure  5.  One  Possible  IRIG  106  Part  2  TmNS  Application  Resources  Hierarchy 


INET  DATA  TRANSFER 

The  iNET  Standards  define  two  delivery  protocols:  LTC  and  RC  Delivery  Protocols.  Typically, 
LTC  data  transfers  are  instantiated  via  Metadata  whereas  RC  data  transfers  are  always 
instantiated  via  a  client  request  to  a  data  server.  All  Metadata-defined  data  transfers  deliver  data 
via  UDP  (over  an  LTC  Data  Channel)  whereas  client  requests  typically  have  data  delivered  via 
TCP.  However,  client  requests  may  also  deliver  data  via  UDP  (over  an  LTC  Data  Channel)  so 
an  LTC  Data  Channel  may  either  be  instantiated  via  Metadata  or  via  a  client  request.  Some 
consider  the  ambiguous  origin  of  an  LTC  Data  Channel  a  point  of  confusion  within  the  iNET 
Standards.  All  LTC  and  RC  data  transfer  statistics  are  reported  via  SNMP  MIB  variables. 

All  client  requests  are  implemented  using  a  customized  version  of  the  Real  Time  Streaming 
Protocol  (RTSP),  an  HTTP -variant  protocol  designed  for  controlling  streaming  media  servers. 
The  iNET-customized  RTSP  requires  an  iNET-specific  Uniform  Resource  Identifier  (URI)  (i.e., 
TmNS  URI),  an  iNET-specific  time  format  (i.e.,  PTP  Time),  and  an  independent  TCP  data 
channel  connection  protocol  (RTSP’s  TCP  delivery  implementation  interleaves  binary  data  onto 
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the  TCP  control  channel).  Once  all  of  the  iNET  customizations  are  applied,  only  a  small  fraction 
of  the  original  RTSP  is  actually  used. 


APPLICATION  DATA  TRANSFER 


A  proposed  adjustment  to  the  iNET  LTC  and  RC  Delivery  Protocols  for  IRIG  106  Part  2  is  to 
define  data  transfer  in  the  context  of  instantiating  and  maintaining  Data  Channels.  A  Data 
Channel  identifies  a  logical  network  connection  used  to  transfer  TmNS  data  between  a  Data 
Source  and  Data  Sink.  A  Data  Channel  is  described  by  the  following  information: 


•  Network  Transport  Characteristics:  includes  destination  address,  port,  transport  protocol 
(UDP  or  TCP),  direction  (send  or  receive),  and  DiffServ  Code  Point  level. 

•  Message  List:  nominally  a  list  of  Message  Definition  IDs. 

•  Time  Range:  comprised  of  a  Start  and  End  time. 

Both  Metadata  and  client  request  interfaces  support  the  sending  and  receiving  of  data  using 
either  UDP  or  TCP.  For  Metadata-defined  data  transfers,  a  new  Data  Channel  element  structure 
is  proposed  to  identify  Message  Definition  IDs  for  transport  along  with  a  specific  set  of  network 
transport  parameters.  While  the  iNET  Standards  restrict  Metadata-defined  data  transfers  to  UDP, 
IRIG  106  Part  2  could  support  both  UDP  and  TCP  for  Metadata-defined  data  transfers  by 
including  the  proposed  Data  Channel  approach. 

Another  proposed  addition  to  IRIG  106  Part  2  involves  client  data  requests.  An  HTTP -based 
data  transfer  interface  could  be  added  to  IRIG  106  Part  2  that  supports  both  sending  and 
receiving  of  data  using  either  UDP  or  TCP.  Figure  6  shows  the  proposed  request-based  data 
transfer  interface  capabilities. 
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Figure  6.  Proposed  IRIG  106  Part  2  Request-based  Data  Transfer  Interface  Capabilities 


The  data  transfer  interface  supports  the  retrieval  of  Data  Channel  information  regardless  of 
whether  a  Data  Channel  is  instantiated  via  Metadata  or  via  a  client  request.  This  highly 
extensible  interface  enables  future  extensions  like  data  compression  requests  (e.g.,  send  data 
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currently  sampled  at  100  hertz  only  at  1  hertz)  and  data  queries  (e.g.,  return  all  samples  outside  a 
specific  threshold  range).  If  adopted,  the  instrumentation  community  could  migrate  away  from 
the  LTC  and  RC  Delivery  Protocols  to  the  HTTP -based  Data  Channel  approach. 


TmNS  MESSAGES 


The  iNET  Standards  define  the  TmNS  Data  Message  format  for  transporting  measurement  data. 
To  facilitate  future  extensibility,  another  proposed  change  for  IRIG  106  Part  2  generalizes  this 
format  into  a  TmNS  Message  by  adding  a  Message  Type  field  to  the  Message  Header.  A  TmNS 
Message  with  a  Message  Type  of  zero  would  be  functionally  equivalent  to  the  current  iNET 
TmNS  Data  Message  format  (comparison  shown  in  Figure  7).  Other  Message  Types  could  be 
added  to  IRIG  106  Part  2  in  the  future. 
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Figure  7.  iNET  TmNS  Data  Message  Compared  to  Proposed  IRIG  106  Part  2  TmNS  Message  Type  0 


TRANSITION  PLAN 

The  proposed  transition  plan  for  IRIG  106  Part  2  includes  the  chapter  structure  and  the  change 
proposals  described  previously.  At  this  time,  these  proposed  changes  have  not  been  approved  by 
the  RCC  TG. 

1.  Change  Proposals  from  iNET  Standards  to  IRIG  106  Part  2: 

a.  Add  Data  Channel  and  associated  elements  to  MDL. 

b.  Add  Data  Channel  Protocol  and  HTTP -based  data  transfer  interface. 

c.  Add  TmNS  Message  Version  2. 

2.  Proposed  Eventual  Removal  from  IRIG  106  Part  2: 

a.  Remove  network  attributes  from  the  MDL  Message  Definition  element;  replaced  by 
Data  Channel  element  (see  la  previously  listed). 

b.  Remove  LTC  and  RC  elements  from  MDL  (see  la  previously  listed). 

c.  Remove  LTC  and  RC  MIB  branches  from  the  TmNS  MIB;  replaced  by  equivalent 
data  statistics  and  control  via  HTTP-data  transfer  interface  (see  lb  previously  listed). 

d.  Remove  LTC  and  RC  Delivery  Protocols;  replaced  by  Data  Channel  Protocol  (see  lb 
previously  listed). 

e.  Remove  TmNS  Message  Version  1;  replaced  by  Version  2  (see  lc  previously  listed). 
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All  items  identified  in  #1  above  may  be  incorporated  into  IR1G  106  Part  2  without  affecting 
existing  iNET-compatible  Network  Nodes.  The  key  to  providing  transitional  support  between  the 
iNET  Standards  and  the  proposed  IRIG  106  Part  2  lies  in  the  Manager  Applications  that 
configure,  control,  and  monitor  TmNS  Applications.  With  respect  to  MDL  Instance  Document 
generation,  the  current  Manager  Applications  could  implement  items  la  above  resulting  in  the 
generation  of  an  MDL  Instance  Document  compatible  with  existing  iNET  Network  Nodes  and 
IRIG  106  Network  Nodes.  For  data  channel  monitoring,  the  Manager  Applications  could  be 
enhanced  to  read  Data  Channel  statistics  via  the  HTTP-based  Data  Channel  interface.  Metadata 
could  indicate  whether  a  particular  TmNS  Application’s  Data  Channel  statistics  are  available  via 
SNMP,  HTTP,  or  both  interfaces.  Implementing  Manager  Applications  that  support  both  types 
of  Network  Nodes  provides  vendors  with  an  elegant  solution  for  the  transitional  coverage  of  their 
existing  iNET  Network  Nodes  while  supporting  new  IRIG  106  Network  Nodes. 

Since  the  proposed  approach  to  IRIG  106  Part  2  defines  both  TmNS  Message  Version  1  and 
Version  2,  vendors  could  augment  all  Data  Sinks  to  support  both.  For  Data  Sources,  a  vendor 
may  choose  to  implement  a  Version  1  /  Version  2  control  to  maintain  compatibility  with  Version 
1  Data  Sinks.  For  the  transition  from  the  RTSP-based  to  HTTP -based  data  transfer  protocol, 
Ground  applications  could  be  augmented  with  the  capability  of  supporting  both  RTSP  and  HTTP 
concurrently.  Although  Test  Article  RTSP-based  systems  could  also  support  both  protocols 
concurrently,  the  limited  Test  Article  hardware  resources  may  make  concurrent  implementation 
impractical.  As  long  as  Ground  applications  support  both  protocols,  the  Test  Article  vendors 
may  continue  to  support  the  RTSP-based  interface.  Figure  8  shows  an  example  of  the  proposed 
dual  standards  Manager  and  Ground  applications. 


iNET  NetworkNode 

IRIG  NetworkNode 

Data 

Data 

Source 

Source 

RTSP  +  4  4 

snmJ 


Data 

Sink 

Ground  Application 

Figure  8.  Example  of  Proposed  Dual  Standards  Manager  and  Ground  Applications 

Once  a  smooth  transition  has  been  accomplished,  items  2a  -  2e  may  eventually  be  removed  from 
IRIG  106  Part  2  at  the  discretion  of  the  RCC  TG. 
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CONCLUSIONS 


Describing  the  iNET  Standards  in  terms  of  the  TCP/IP  Model  provides  an  excellent  foundation 
for  IRIG  106  Part  2.  While  preserving  the  iNET  Standards’  underlying  requirements,  the 
proposed  approach  for  IRIG  106  Part  2  evolves  the  iNET  Standards  by  implementing  an 
application-centric  paradigm.  The  proposed  TmNS  Application  Resources  Hierarchy 
encompasses  all  application  level  communication  by  including  both  SNMP  and  HTTP 
application  protocols.  The  proposed  Data  Channel  protocol  unifies  the  concept  of  statically- 
defined  and  dynamically-defined  Data  Channels.  Thanks  to  the  flexibility  of  the  proposed 
enhancements,  the  transition  plan  for  migrating  from  the  iNET  Standards  to  the  proposed  IRIG 
106  Part  2  minimizes  the  overall  impact  of  this  transition  on  existing  vendors’  hardware.  At  this 
time,  these  proposed  changes  have  not  been  approved  by  the  RCC  TG. 
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